Dans l’écosystème ROCm, portabilité source est souvent confondue avec une équivalence de performances. Bien que le code HIP portable permet qu’une même base de code s’exécute sur différents fournisseurs de matériel (AMD et NVIDIA), atteindre des débits optimaux exige de reconnaître que la portabilité source et les performances binaires sont des préoccupations distinctes.
1. Le paradoxe de la portabilité
Un programme HIP est portable au niveau source, ce qui signifie que la syntaxe et la logique restent constantes. Toutefois, l’architecture d’instruction sous-jacente (ISA) diffère considérablement entre les générations (par exemple, AMD GCN vs. RDNA). Une compilation « naïve » ignorant ces différences peut entraîner des régressions importantes de performance.
2. Sensibilité à l’architecture
Pour tirer le maximum de performances, les bons binaires restent sensibles à l’architecturele compilateur doit optimiser l'allocation des registres, la planification des ondes/fils (wavefront/warp) et les schémas d'accès mémoire spécifiquement pour les unités de calcul de la GPU cible. Oublier de préciser l'architecture cible empêche l'utilisation de matériel spécialisé comme les unités de multiplication-ajustage matriciel (MFMA).
La compatibilité fonctionnelle n’implique pas une équivalence de performance au niveau binaire.
3. L’obligation du système de construction
Dépasser le « Hello World » exige une chaîne de construction sophistiquée (comme CMake) qui gère la génération de plusieurs chemins binaires optimisés à partir d’un seul arbre source, garantissant que les bonnes instructions atteignent le bon matériel.